From Date Correction to SOA Migration: Evolving Reengineering Methods

This paper discusses the changing nature of Software Reengineering projects over the past 10 years. It is based on numerous observations in the reengineering community and on the author’s own experience in large customer projects. The projects can be roughly grouped into three clusters: ‚classic’ migrations, refurbishments and consolidations (e.g. database migration, consolidation of customer keys after mergers); pervasive, externally time-boxed adoptions and transitions (e.g. Year 2000 correction, Euro currency introduction); and businessdriven, enterprise-scale transformations (e.g. core-system replacement, SOA migration). Looking at real-life project examples, we will see how these three categories are related. Large projects have turned out most successful where new technologies could be used to directly support a suitable reengineering methodology. This holds in particular for the rapidly evolving SOA migration projects. 1 Reengineering Projects The term Reengineering is used here in a wide sense, meaning all activities that aim at technical improvement and continued development of productive systems. The motivations include extending the life of a reliable and suitable system, while protecting the investments put in that system. This concept of Reengineering corresponds rather to what we used to call Redevelopment for some time in IBM: the spectrum from application portfolio assessment via application and program understanding to restructuring, migration and even reverse engineering. We can determine how our project approaches have evolved when we look at projects of the same kind, e.g. currency migrations. Euro transitions had their start time around 1997, and they are now heavily requested in the countries that have recently obtained EU accession. Apart from the Euro, there are in-country conversions to increase the granularity of a given currency, as we have perceived in Bulgaria, Turkey or Venezuela, e.g. moving from 1.000.000 old units to 1 new unit, as for example in the new (yeni) Turkish lira. Currency migrations also have to deal with amount field ‘anomalies’: we cannot rely on an amount field simply holding an amount. In the very first Workshop Software